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LORIN, Administrative Patent Judge. 



ORDER REMANDING TO THE EXAMINER 

This is an appeal from a decision of the Examiner rejecting claims 1, 3, 4, 
and8-l2. 1 35 U.S.C. § 134 (2002). We have jurisdiction under 35 U.S.C. § 6(b) 
(2002). 



Claim 2 has been canceled and claims 5-7 and 13-17 have been withdrawn. 



Appeal No. 2007-0695 
Application No. 09/837,041 



Page 2 



Our review of the record leads us to conclude that this appeal is not in a 
condition for a decision. Pursuant to 37 C.F.R. § 41.50(a)(1), we remand the 
application to the Examiner for further explanation of the rejection. 

The invention is directed to a system for processing eCommerce requests 
from an original format to a transformed format. The system employs an 
application configured to process the request in the transformed format by 
receiving the request in the original format and mapping it to the transformed 
format. The system includes a specification document configured to produce 
metadata defining a relationship between request data in the original format and 
the transformed format. The system further includes a flow manager configured to 
use the metadata to map the request in the original format to the request in the 
transformed format and to call the application configured to process the request in 
the transformed format. Specification, p. 4. 

Claims 1, 3, 4, and 8-12 are finally rejected under 35 U.S.C. § 102(e) as 
being anticipated by Meltzer (U.S. Patent No. 6,125,391). 

Claim 1 reads as follows: 

1. A system for handling eCommerce requests, comprising: 

(a) at least one application configured to process a request in a 
transformed format, wherein the request is received from one of a plurality 
of requesting entities in an original format and mapped to the transformed 
format; 

(b) at least one specification document configured to produce 
metadata defining a relationship between data of the request in the original 
format and data of the request in the transformed format, wherein the 
metadata comprises a plurality of metadata instances each configured to 
support a different request protocol; and 
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(c) a flow manager configured to utilize the metadata to map the 
request in the original format to the request in the transformed format and to 
call the at least one application. 

The Examiner provided an element-by-element analysis of the claims 
showing where in Meltzer each claim limitation is described. (Answer 3-4). 

Appellants argued that Meltzer fails to describe element (b) of claim 1 . 

(Appeal Br. 11-15). Element (b) reads : 

(b) at least one specification document configured to produce metadata 
defining a relationship between data of the request in the original format and 
data of the request in the transformed format, wherein the metadata 
comprises a plurality of metadata instances each configured to support a 
different request protocol. 

Regarding element (b), the Examiner found that Meltzer showed this element, 

explaining it this way: 

(b) at least one specification document configured to produce metadata 
defining a relationship between data of the request in the original format and 
data of the request in the transformed format ([Meltzer,] Fig 9), wherein the 
metadata comprises a plurality of metadata instances each configured to 
support a different request protocol ([Meltzer,] col. 32, lines 12-55); 

Answer 3. 

We reproduce Fig. 9 of Meltzer below. 



2 Examiner's Answer ("Answer," mailed Jul. 11, 2006). 

3 Appeal Brief ("Appeal Br.," filed Apr. 6, 2006). 
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Fig. 9 is a flowchart illustrating the processes of building a business interface 
definition according to the present invention. 



We reproduce column 32, lines 12-55 of Meltzer below. 
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The CBL creates a single source from which almost all of the pieces 
of a system can be automatically generated by a compiler. The CBL works 
by extending SGML/XML, which is normally used to formally define the 
structures of particular document types, to include specification of the 
semantics associated with each information element and attribute. The 
limited set of (mostly) character types in SGML/XML can be extended to 
declare any kind of datatype. 

Here is a fragment from the CBL definition for the "datetime" 
module: 



- datetime.mod Version: 1.0 --> 

<!-- Copyright 1998 Veo Systems, Inc. --> 



<! ELEMENT year (#PCDATA)> 
<!ATTLIST year 

schema CDATA #FIXED "urn:x-veosystems:stds:iso:8601:3.8" 
<! ELEMENT month (#PCDATA)> 
<!ATTLIST month 

schema CDATA #FIXED "url:x-veosystems:stds:iso:8601:3.12" 



In this fragment, the ELEMENT "year" is defined as character data, 
and an associated "schema" attribute, also character data, defines the schema 
for "year" to be section 3.8 of the ISO 8601 standard. 

This "datetime" CBL module is in fact defined as an instance of the 
Schema DTD. First, the module name is defined. Then the "datetime" 
element "YEAR" is bound to the semantics of ISO 8601: 



<!DOCTYPE SCHEMA SYSTEM "schema.dtd"> 
<SCHEMA><H 1 >Date and Time Module</Hl> 

<ELEMNTTYPENAME="year"DATATYPE="YEAR"><MODEL> 
<STRING 
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DATATYPE= H YEAR"x/STRING></MODEL> 

<ATTDEF NAME=:schema:iso8601 M DATATYPE="CDATA"> 

<FIXED>3.8 

Gregorian calendar</FIXED></ATTDEF></ELEMENTTYPE> 



We are unable to find any explicit mention of element (b) in Fig. 9 or 
column 32, lines 12-55 of Meltzer. Moreover, without more explanation, we are 
unable to understand how these disclosures inherently describe metadata which 
comprises a plurality of metadata instances each configured to support a different 
request protocol. Appellants made this same point in their briefs (see Appeal Br. 
11-13 and Reply Br. 4 3-4). The Examiner responded to Appellants' concern by 
stating, in part, that "there must be metadata produced to define what the 
relationship is since the data needs to be transformed back to the original format 
when sent to the requestor (13 1 1 5 )." Answer 6. The Examiner did not further 
elaborate. The Examiner should have. 



4 Reply Brief ("Reply Br.,' 5 filed Sep. 11, 2006). 

5 Refers to element 1311 ("Convert to Document") in Fig. 13 reproduced below: 
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Given that "[a] claim is anticipated only if each and every element as set 
forth in the claim is found, either expressly or inherently described, in a single 
prior art reference," Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 
631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987), cert denied, 484 U.S. 827 (1987), 
element (b) of the claimed system must be described, either expressly or 
inherently, in Meltzer if the claims are to be rejected as being anticipated by 
Meltzer. The Examiner clearly states that Meltzer describes all the elements of the 
claimed system. But we have the impression from reading the Examiner's Answer 
that, with respect to element (b) of the claimed system, the Examiner takes the 
position that Meltzer inherently describes that element. We need more explanation 
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FIG. 13 



Fig. 13 is a flow chart illustrating the process of registering participants at a market 
maker node according to the present invention. 
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as to why the Examiner finds Meltzer inherently discloses element (b) in order to 
ascertain the strength of that position. The Examiner's response that "there must 
be metadata produced to define what the relationship is since the data needs to be 
transformed back to the original format when sent to the requestor (13 1 1)" is 
insufficient. The Examiner must make it clear on the record why "there must be 
metadata produced" in using Meltzer' s system. Without a logical explanation why 
Meltzer would necessarily produce metadata to "defin[e] a relationship between 
data of the request in the original format and data of the request in the transformed 
format, wherein the metadata comprises a plurality of metadata instances each 
configured to support a different request protocoland explanation," the Examiner's 
position amounts to an unsupported conclusory statement. 

Accordingly, we remand the application to the Examiner for further 
explanation as to why element (b) of the claimed system is inherently described in 
Meltzer. "To serve as an anticipation when the reference is silent about the asserted 
inherent characteristic, such gap in the reference may be filled with recourse to 
extrinsic evidence. Such evidence must make clear that the missing descriptive 
matter is necessarily present in the thing described in the reference, and that it 
would be so recognized by persons of ordinary skill." Continental Can Co. USA v. 
Monsanto Co,, 948 F.2d 1264, 1268, 20 USPQ2d 1746, 1749 (Fed. Cir. 1991). 
"[T]his modest flexibility in the rule that anticipation requires that every element 
of the claims appear in a single reference accommodates situations in which the 
common knowledge of technologists is not recorded in the reference; that is, where 
technological facts are known to those in the field of the invention, albeit not 
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known to judges." Continental Can Co., 948 F.2d at 1268, 20 USPQ at 1749-50.). 

The Examiner should also respond to Appellants' argument that Meltzer 
does not show element (c): "a flow manager configured to utilize the metadata to 
map the request in the original format to the request in the transformed format." 
(App. Br. 12-13). The Examiner does not appear to respond to this argument and 
thus appears to stand on the initial finding that this element is shown in Fig 1 3 [see 
footnote 3]. Answer 3. However, as with element (b), the Examiner has not clearly 
shown that Fig. 13 of Meltzer inherently describes the use of metadata. 

This remand to the examiner pursuant to 37 CFR § 41.50(a)(1) (effective 
September 13, 2004, 69 Fed. Reg. 49960 (August 12, 2004), 1286 Off. Gaz. Pat. 
Office 21 (September 7, 2004)) is made for further consideration of a rejection. 
Accordingly, 37 CFR § 41.50(a)(2) applies if a supplemental examiner's answer is 
written in response to this remand by the Board. 

No time period for taking any subsequent action in connection with this 
appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. 
§ 1.136(a)(l)(iv)(2006). 



REMAND 
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